nit: The fetchOneMessageTime field is stored as long but cast to int in the getter, can it risk overflow for large Duration values? Should we add: Add validation to reject values > Integer.MAX_VALUE , or can we make this Duration too?

Good catch. Cannot do much about this, as the pulsar client requires an int value for this, and Duration.toMillis() return a long. I don't think there can be any case, where someone types in a duration that turns into a bigger number than Integer.MAX_VALUE. Since I can type in durations like 5d, having an explicit check that says you need to type in a lower number than 2147483647 would be more helpful than the cast exception.

Well, we could leave this as an int, but it is much better UX to be able to write duration strings than raw millis, so I would consider the current state better then it was before.